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DETAILED ACTION 
Claim Rejections - 35 USC § 102 

1. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by another filed 
in the United States before the invention by the applicant for patent or (2) a patent granted on an application for 
patent by another filed in the United States before the invention by the applicant for patent, except that an 
international application filed under the treaty defined in section 351(a) shall have the effects for purposes of this 
subsection of an application filed in the United States only if the international application designated the United 
States and was published under Article 21(2) of such treaty in the English language. 

2. Claims 1-3,5,10-16,18,31,38-43,45,58 and 65 are rejected under 35 U.S.C. 102(e) as 
being anticipated by Buyukkoc (US 6.463.062). 

Regarding claims 1 and 39, Buyukkoc discloses an intelligent policy server (see FIG. 7- 
9, central Routing Status Database server, RDS) method in an synchronous Transfer Mode 
(ATM) network (see FIG. 7-9, ATM network; see col. 19, line 55-60) having an ingress switch 
(see FIG. 9, ATM switch 922) and an egress switch (see FIG. 9, ATM sv^tch 924), wherein said 
ingress switch serves an ingress device (see FIG. 9, switch 912) operated by a calling party (see 
FIG. 9, User 902) and said egress switch serves an egress device (see FIG. 9, Switch 914) 
operated by a called party (see FIG. 9, user 904); see col. 19, line 61 to col. 20, line 24), 
comprising the steps of: 

receiving, in said ingress switch, a signaling message from said ingress device (see FIG. 
9, step 810, edge node receive a new call; see col. 19, line 19-26; also see FIG. 10, step 
1005,1010,1015,1020,1025,1030; see col. 20, line 50-67); 

providing said signaling message to a signaling intercept processor (see FIG. 7, a link 750 
to Regional RSD server, RRSD, 740; see col. 13, line 22-46) associated with said ingress switch 
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(see col. 47 to col. 14, line 5; see FIG. 8, step 820; see col. 19, line 25-30; edge node send a call 
query/message to RSD; also see FIG. 10, step 1035); 

propagating said signaling message to a policy server (see FIG. 7, a link 770 to central 
RDS server 730, i.e.. Signaling Control Point, SCP), said policy server including at least one 
policy profile having a plurality of policy features (see col. 14, line 9 to col. 15, line 50; see col. 
10, line 10-20; see col. 1 1, line 1-16; see col. 13, line 1-6, 29-67; RSD contents consists 
connection rules/policy such as connectively information, threshold, quality of service, capacity, 
and/or status of loading/congestion); 

determining in said policy server, based at least in part on said signaling message, if a 
particular policy feature is to be invoked (see FIG. 8, step 840; see FIG. 10, steps 1035,1040; see 
col. 13, line 1-7; 64 to col. 14, line 67; Tables VII-IX; decide how to route the call in accordance 
RSD contents); 

if so, determining v^hether a policy condition associated v^th said particular policy 
feature is satisfied with respect to said signaling message (see FIG. 8, step 840; see FIG. 10, 
steps 1035,1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, 
line 19-30; determines/decides whether the load/congestion/priority/bandwidth/routes conditions 
are met/fulfilled); 

establishing a connection path between said ingress switch and said egress switch based 
on said determination tiiat said policy condition is satisfied by said signaling message (see FIG. 
8, step 850, 860, 870; see FIG. 10, steps 1045,1050,1055; see col. 14, line 1-65; see col. 19, line 
35-50; see col. 21, line 40-50; setting/establishing the call when 
load/congestion/priority/bandwidth/routes conditions are met/fulfilled). . 
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Regarding claim 14, Buyukkoc discloses an Asynchronous Transfer Mode (ATM) 
network (see FIG. 7-9, ATM network; see col. 19, line 55-60) for effectuating intelligent policy 
features with respect to a call to be established between two parties (see FIG. 9, a connection 
user 904 and 902) via a virtual channel connection (see col. 20, line 1-45; a virtual circuit); see 
col. 19, line 61 to col. 20, line 24, comprising: 

an ATM switch (see FIG. 9, ATM switch 922) serving a customer premises equipment 
(CPE) operated by a party with respect to said call (see FIG. 9, CPE User 902 connects TDM 
switch 912; see col 19, line 64 to col. 20, line 25); 

a signaling intercept processor (see FIG. 7, Regional RSD server, RRSD, 740; see col. 
13, line 22-46) associated with said ATM switch for intercepting a signaling message relative to 
said call (see col. 47 to col. 14, line 5; see FIG. 8, step 820; see coL 19, line 25-30; edge node 
send a call query/message to RSD; also see FIG. 10, step 1035); 

a policy server (see FIG. 7, central RDS server 730, i.e., Signaling Control Point, SCP) 
associated with said signaling intercept processor, said policy server including at least one policy 
profile having a plurality of policy features (see col. 14, line 9 to col. 15, line 50; see col. 10, line 
10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; RSD contents consists connection 
rules/policy such as connectively information, threshold, quality of service, capacity, and/or 
status of loading/congestion), wherein said policy server operates to effectuate a particular policy 
feature with respect to said call when triggered by said signaling message received from said 
signaling intercept processor (see FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 13, 
line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; RDS 



Application/Control Number: 09/766,943 Page 5 

Art Unit: 2661 

determines/decides whether a load/congestion/priority/bandwidth/route condition is met/fulfilled 
for the new connection). 

Regarding claims 2, 15, and 42, Buyukkoc discloses wherein said signaling message 
comprises a Connect message (see FIG. 8, step 850, a message which contains a route for new 
call is the connect message in ATM signaling/SS7; see col. 19, line 19-25, 40-45; see col. 20, 
line 39-45). 

Regarding claims 3,5,16,18,43 and 45, Buyukkoc discloses wherein said signaling 
message comprises an Add Party or setup message (see FIG. 8, steps 820,830; a message which 
contains a new call requesting for a route is the SETUP/adding party message in ATM 
signaling/SS7; see col. 19, line 19-31; see col. 20, line 46-52; see col. 20, line 39-45; see col. 21, 
line 19-25). 

Regarding claim 10, Buyukkoc discloses a maximum burst size limit feature (see col. 
14, line 15-65; acceptable/maximum load/size before the call are blocked). 

Regarding claim 11, Buyukkoc discloses an aggregated bandwidth limit feature (see col. 
17, line 30-40; see col. 13, line 45-47; total bandwidth). 

Regarding claim 12, Buyukkoc discloses a service class selection feature (see col. 10, 
line 50-55; see col. 18, line 26-45; class-of-service). 

Regarding claim 13, Buyukkoc discloses a maximum concurrent call limit feature (see 
col. 14, line 15-65; acceptable/maximum call load/limit). 

Regarding claims 31 and 58, Buyukkoc discloses a service class selection feature for 
specifying a service class vAth respect to a network port used by said party (see col. 10, line 50- 
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55; see col. 18, line 26-45; see FIG. 9, trunk/port 932; see col. 20, line 1-10; selecting a class-of- 
service for a port/link/trunk/circuit used by the call). 

Regarding claims 38 and 65, Buyukkoc discloses a maximum concurrent call limit 
feature for specifying the total number of calls allowed concurrently with respect to a network 
port used by said party (see col. 14, line 10 to col. 15, line 50; see FIG. 9, trunk/port 932; see col. 
20, line 1-10; acceptable/allowable total number of calls threshold/limit for a trunk/port). 

Regarding claims 40, Buyukkoc discloses establishing a virtual channel connection 
between said party and another party for said call (see col. 20, line 5-45; virtual connection 
between users). 

Regarding claims 41, Buyukkoc discloses denying a virtual channel connection for said 
call (see col. 14, line 44-47; see col. 1, line 66-67; call is block, thereby, blocking the virtual 
connection due to congestion). 

Claim Rejections - 35 USC § 103 

3. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

4. Claim 4, 17, and 44 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc in view of Noake (US006751222B1). 

Regarding claims 4,17, and 44, Buyukkoc does not explicitly disclose a release 
message. However, a release message is well know in the ATM signaling/SS7 in order to 
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disconnect the call. In particular, Noake teaches a release message (see FIG. 4, RELEASE 
message; see col. 8, line 9-39). Therefore, it would have been obvious to one having ordinary 
skill in the art at the time the invention was made to provide a release message, as taught by 
Noake in the system of Buyukkoc, so that it would make effective use of a band and the 
respective apparatus by transmitting connection information, and by sending/receiving a'release 
message it will notify to stop the cell assembling and disassembling processes; see Noake col. 2, 
line 55-64; col. 8, line 19-24. 

5. Claims. 6-9,19-21,23,25,46-48,50 and 52 are rejected under 35 U.S,C. 103(a) as being 
unpatentable over Buyxikkoc in view of Christie'656 (US006690656B1). 

Regarding claims 6, 8 and 9, Buyukkoc does not explicitly disclose a source address 
validation/screening and a destination address screening. However, a source address 
validation/screening is well known in the ATM signaling/SS7. In particular, Christie'656 teaches 
a source address validation/screening and a destination address screening (see FIG. 7; see col. 7, 
line 9-19, 35-45; checking/validating caller nimiber in ANI and verifying a dial number). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
invention was made to validate/verify the caller number and dial number, as taught by 
Christie'656 in the system of Buyukkoc, so that it would can validate the calls and generate a 
billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39-45. 

Regarding claims 19 and 46, Buyukkoc discloses accessing said ATM network through 
a particular network port associated with said CPE (see FIG. 9, accessing Switch 922 through the 
trunk/port 932; see col. 20, line 1-10). 
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Buyukkoc does not explicitly disclose a source address validation for ensuring that said 
party is an authorized party for accessing the network. 

However, a source address validation for ensuring that said party is an authorized party 
for accessing the network is well known in the art of signaling in order to established the call. In 
particular, Christie*656 teaches a source address validation for ensuring that said party is an 
authorized party for accessing the ATM network (see FIG. 7; see col. 7, line 9-19, 35-45; 
checking/validating caller number in ANI for verification for accessing ATM network). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
invention was made to validate/verify the caller number to access the ATM network, as taught by 
Christie*656 in the system of Buyukkoc, so that it would can validate the calls and generate a 
billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39-45. 

Regarding claims 20 and 47, Buyukkoc discloses wherein said particular network port 
is a Customer Logical Port (see col. 4, line 20-40; see col. 5, line 20-26; edge node/switch 
provides logical connection/port between customer and the network). Christie*656 also discloses 
a Customer Logical Port (see col. 4, line 35-40; 60-67; a logical/virtual port/link). 

Regarding claims 21 and 48, Buyukkoc discloses wherein said particular network port 
is a full physical port (see FIG. 9, physical trunk/port 932; see col. 20, line 1-10). 

Regarding claims 23 and 50, Buyukkoc does not explicitly disclose a destination 
address screening for defining a plurality of address to which said party can effectuate said call. 
However, a destination address/number validation/screening for defining a plurality of 
address/numbers to which said party can effectuate said call is well known in the signaling with 
SCP. In particular, Christie'656 teaches a destination address screening for defining a plurality of 
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address to which said party can effectuate said call (see FIG. 7; see col. 7, line 9-19, 35-45; see 
col. 15, line 40-60; see col. 2, line 1-15; verifying a dial number from the list of numbers where 
the call needs to be connected). Therefore, it would have been obvious to one having ordinary 
skill in the art at the time the invention was made to validate/verify dial number from the list of 
number to establish the call, as taught by Christie*656 in the system of Buyukkoc, so that it 
would can validate the calls and generate a billing record; see Christie'656 col. 3, line 12-22; col. 
7, line 39-45. 

Regarding claims 25 and 52, Buyukkoc does not explicitly disclose a source address 
screening for defining a plurality of address from which said call can be initiated to said party. 
However, a source address/number validation/screening for defining a plurality of address from 
which said call can be initiated to said party is well known in the signaling with SCP. In 
particular, Christie'656 teaches a source address screening for defining plurality of address from 
which said call can be initiated to said party (see FIG. 7; see col. 7, line 9-19, 35-45; see col. 15, 
line 40-60; see col. 2, line 1-15; verifying a caller number, from the list of numbers, to initiate a 
call/connection). Therefore, it would have been obvious to one having ordinary skill in the art at 
the time the invention was made to validate/verify caller number from the list of number to 
initiate a call, as taught by Christie'656 in the system of Buyukkoc, so that it would can validate 
the calls and generate a billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39-45. 

6. Claims 7, 22 and 49 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc in view of Farris (US006 154445 A). 



r 
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Regarding claim 7, Buyukkoc does not explicitly disclose a maximum call attempt rate 
limit. However, having a maximum call attempt rate limit/threshold is v^ell known in the 
signaling/SS7. In particular, Farris teaches a maximum call attempt rate limit (see col. 14, line 1- 
12; see col. 11, line 5-17; acceptable/maximum specified rate of call attempts). Therefore, it 
would have been obvious to one having ordinary skill in the art at the time the invention was 
made to provide acceptable/maximum specified rate of call attempts, as taught by Farris in the 
system of Buyukkoc, so that it would can detect the predetermined events and/or imminence of 
predetermined events, and then blocking or controlling those events from their incipiency; see 
Farris col. 14, line 1-6. 

Regarding claim 22 and 49, Buyukkoc discloses the number of setup messages as 
described above in claim 18. 

Buyukkoc does not explicitly disclose a maximum call attempt rate limit for monitoring 
the number of messages received from said party over a predetermined period of time. However, 
having a maximimi call attempt rate limit for monitoring the number of messages received from 
said party over a predetermined period of time is well known in the art of signaling and network 
management. In particular, Farris teaches a maximum call attempt rate limit for monitoring the 
number of setup messages received from said party over a predetermined period of time (see col. 
14, line 1-12; see col. 1 1, line 5-56; acceptable/maximum specified rate of call attempts for 
monitoring and determining the number of setup/ISUP messages from calling party per time 
period). Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide acceptable/maximum specified rate of call attempts and 
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monitoring process, as taught by Farris in the system of Buyukkoc, for the same motivation as 
stated above in claim 7. 

7. Claims 27-29 and 54-56 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc in view of Kobayashi (US 5,896,371). 

Regarding claims 27 and 54, Buyukkoc discloses a maximum burst size limit feature 
associated with said call (see col. 14, line 15-65; acceptable/maximum load/size before the call 
are blocked). 

Buyukkoc does not explicitly disclose limiting a burst-size request. However, limiting a 
burst-size request is well known in the art of ATM. In particular, Kobayashi teaches a maximum 
burst size limit feature for limiting a burst-size request associated with said call (see FIG. 6; see 
col. 12, line 55 to col. 13, line 35; a limiting/setting/changing the number of cells transmitted in 
each call). Therefore, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to limit the number of cells transmitted in each call, as taught by 
Kobayashi in the system of Buyukkoc, so that it would provide a flow control performed 
cooperatively by the network and the terminal equipment and call accepted control is simplified; 
see Kobayashi col. 7, line 46-52; col. 8, line 40-45. 

Regarding claims 28 and 55, Kobayashi discloses the number of packets per second 
allowed to be transmitted to said ATM network with respect to said call (see FIG. 6; see col. 12, 
line 55 to col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to transmit in 
each call to ATM network). Therefore, it would have been obvious to one having ordinary skill 
in the art at the time the invention was made to provide the number of packets per second 
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requested to be transmitted, as taught by Kobayashi in the system of Buyukkoc, for the same 
motivation as above in claim 27 and 52. 

Regarding claims 29 and 56, Kobayashi discloses the number of packets per second 
allowed to be received by said party from said ATM network with respect to said call (see FIG. 
6; see col. 12, line 55 to col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to 
received in each call from ATM network). Therefore, it would have been obvious to one having 
ordinary skill in the art at the time the invention was made to provide the number of packets per 
second requested to be received, as taught by Kobayashi in the system of Buyukkoc, for the same 
motivation as above in claim 27 and 52. 

8. Claims 30 and 57 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc in view of Smith (US006222823B1). 

Regarding claims 30 and 57, Buyukkoc discloses an aggregated bandwidth limit feature 
for a particular network port by said party (see FIG. 9, physical trunk/port 932; see col. 20, line 
1-10; col. 17, line 30-40; see col. 13, line 45-47; total bandwidth for the port/link). 

Buyukkoc does not explicitly disclose for determining a maximum bandwidth allowable 
and authorized for use. However, determining the maximum bandwidth allowable for a particular 
port authorized for use by said party is well known in the art of ATM. In particular, Smith 
teaches determining the maximum bandwidth allowable for a particular port authorized for use 
by said party (see FIG. 1-2; see col. 9, line 5-45, and abstract; determining 
predetermined/allowable/authorized bandwidth for a particular port/connection of end station). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
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invention was made to determining predetermined/allowable/authorized bandwidth for a 
particular port/connection of end station, as taught by Smith in the system of Buyukkoc, so that it 
would cause the system control means to allocate a predetermined bandwidth and balance the 
bandwidth; see Smith col. 2, line 35-67; col. 9, line 21-25. 

9. Claims 32-37 and 59-64 are rejected under 35 U.S.C. 103(a) as being impatentable over 
Buyukkoc in view of Kilkki (US006041039A). 

Regarding claims 32-37 and 59-64, Buyukkoc discloses service class as described 
above in claim 31 and 58. Buyukkoc further discloses constant bit rate service (CBR) and 
variable bit rate service (VBR) (see col. 1, line 50-60). 

Buyukkoc does not explicitly disclose a real-time VBR service, non-real time VBR, 
unspecified bit-rate (UBR), and available bit-rate (ABR). However, the ATM class of services a 
real-time VBR service, non-real time VBR, unspecificed bit-rate (UBR), and available bit-rate 
(ABR) is well known in ATM standard. In particular, Kilkki teaches CBR, VBR, a real-time 
VBR service, non-real time VBR, unspecified bit-rate (UBR), and available bit-rate (ABR) (see 
col. 1, line 54-67). Therefore, it would have been obvious to one having ordinary skill in the art 
at the time the invention was made to provide quality of service class defined by ATM standard, 
as taught by Kilkki in the system of Buyukkoc, so that it would provide a capability to manage 
increases in network load, supporting both real-time and non-real time application, and offering, 
in certain circumstances, a guaranteed level service quality; see Kilkki col. 1, line 44-53, also by 
using the ATM standard services, it will enable the service provider to interoperate between 
multi- vendor networks. 
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Allowable Subject Matter 

10. Claims 24,26,51 and 43 are objected to as being dependent upon a rejected base claim, 
but would be allowable if rewritten in independent form including all of the limitations of the 
base claim and any intervening claims. 

Response to Arguments 

1 1 . Applicant's argimients filed 2/27/06 have been fully considered but they are not 
persuasive. 

Regarding claims 1-23,25,27-50,52,54-65, the applicant argued that, "...Buyukkoc 
does not disclose or suggest propagation a signaling message to a policy server, where the policy 
server includes at least one policy profile having a plurality of policy features; determining in 
said policy server, based at least in part on said signaling message, if a particular policy feature is 
to be invoked... " in page 8, paragraph 1-2; page 9, paragraph 1,2; page 10, paragraph 2,4; page 

12. paragraph 2,3,5; page 13, paragraph 3,4; page 14, paragraph 2; page 16, paragraph 2-4; page 
17, paragraph 5-6; page 18, paragraph 2-6; page 19, paragraph 3-5; page 20, paragraph 1-6; page 
21; , paragraph 2-4. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. 

Buyukkoc discloses propagating said signaling message (see FIG, 8, Step 820; see FIG. 
10, step 1030; sends setup for a new call to RSD) to a poUcy server (see FIG. 7, a link 770 to 
central RDS server 730, i.e., Signaling Control Point, SCP), said policy server including at 
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least one policy profile having a plurality of policy features (see col. 14, line 9 to col. 15, line 
50; see col. 10, line 10-20; see col, 11, line 1-16; see coL 13, line 1-6, 29-67; RSD contents 
consists connection rules/policy such as connectively information, threshold, quality of 
service, capacity, and/or status of loading/congestion); 

determining in said policy server, based at least in part on said signaling message, if a 
particular policy feature is to be invoked (see FIG. 8, step 840; see FIG. 10, steps 1035,1040; 
see col. 13, line 1-7; 64 to col. 14, line 67; Tables VII-IX; decide how to route the caU in 
accordance RSD contents); 

if so, determining whether a policy condition associated with said particular policy 
feature is satisfied with respect to said signaling message (see FIG. 8, step 840; see FIG. 10, 
steps 1035,1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, 
line 19-30; determines/decides whether the load/congestion/priority/bandwidth/routes 
conditions are met/fulfilled). 

I) Examiner assert the applicant's "policy server" as Buyukkoc's "RSD" as set forth 
above for the following reasons: 

Applicant disclosure (summary of invention) discloses , page 7, lies 1 1-14, 17-18 as 
follows: 

"the present invention is related to an intelligent policy server system and method for 
providing multiple service policy service policy feature or option and for managing bandwidth 
usage in the an ATM network. . . which policy server is also referred as a Multi-Service Control 
Point or MSCP..." 

As recited in above rejection, Buyukkoc discloses in col. 1 1, line 5-15, as follows: 

"The RSD may be used in conjunction with a nvmiber of other innovations. For example, 
the RSD may be used in conjunction with a service control point (SCP) of an Intelligent 
network. An SCP determines an appropriate destination for a call having more than one possible 
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destination, such as a call to the 800 number of a large customer that may be routed to one of a 
number of regional service centers, based on factors such as the availability of representatives in 
the various service centers. The RSD may be accessed after an SCP or at the same time as 
an SCP, and the same server may provide RSD and SCP functionality." (Emphasis added) 



Thus, it is clear that Buyukkoc's RSD is the applicant "policy server". 

II) Examiner asserts the applicant's "policy profile having a plurality of policy features" 
as RSD's "connection rules/policy such as connectively information, threshold, quality of 
service, capacity, and/or status of loading/congestion". 

Applicant disclosure discloses , page 7, lies 1 1-14, 19-21; page 7, line 1-7 as follows: 

"the present invention is related to an intelligent policy server system and method for 
providing multiple service policy service policy feature or option and for managing bandwidth 
usage in the an ATM netv^ork. A return message from the policy server determines whether 
a call connection can be made through the network or not... Depending on the triggers 
associated with a signaling message received in the edge switch, a particular feature is invoked 
and executed by the policy server... burst-size limit, class-of-service provisioning, maximum 
concurrent call connections in progress, bandwidth control... are provided as exemplary 
features implemented in a presently preferred exemplary embodiment of the present invention.." 
(Emphasis added) 

As recited in above rejection, Buyukkoc discloses as follows: 

"For each (source, destination) pair in the network, the RSD contains some or all of the 
following information. Depending on the needs and size of the network, a "destination" could be 
a terminating switch or it could be a trunk group or virtual path. Connectivity information 
regarding the set of routes that can be used to interconnect the source and destination. 
Information about alternate routes. Information on the capacity of each route in the network. 
Status of all of the routes in the network. Status could be in the form of free or available 
capacity or utilization on each link, or could be a status indicator such as **lightly loaded**, 
"heavily loaded**, **extreme congestion**. The data needed to manage routing features 
responsible for distributing load to multiple physical destinations based on some rule or 
logic. 

Tables VIMX show a sample RSD for the network of FIGS. 1-5. The Tables show 
information for only a limited number of routes, whereas a real RSD would have more complete 
information. In particular, if there are k routes between each pair of edge nodes and n edge 
nodes in the network, the total number of rows in the Route Status Table (Table IX) is kn(n-l)/2. 
The .alpha.-link, .beta.-link, source, destination, and VPI numbers of Tables VII-IX refer to the 
reference numbers of FIGS. 1-5. 
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Table VII contains the current usage of each .alpha.-link. Table VII also contains 
two congestion thresholds for each link, which define three congestion status ranges — 
referred to as "green," "yellow," and "red," in increasing order of congestion. A status of 
"green" may mean that the route has plenty of capacity left and that new calls can be routed there 
with no difficulty. A status of "yellow" may mean that the link is beginning to get congested and 
that alternate routes should be used if available. A status of "red" may mean to avoid using the 
route if at all possible. For example, if a call arrives and all its possible paths are "red," the call 
may be blocked, depending upon its priority. For example, .alpha.-link 214 has a "green" 
congestion status when the usage is not greater than 1.4 Gbps, a "yellow" congestion status when 
the usage is greater than 1.4 Gbps and not greater than 1.8 Gbps, and a "red" congestion status 
when the usage is greater than 1.8 Gbps. The current usage of .alpha.-link 214 is 1.312 Gbps, so 
the congestion status is "green." The current usage and congestion status of each link are 
periodically updated. It may be desirable to define different congestion thresholds for different 
links, due to factors such as different capacities and different expected usage volumes. In 
addition, it is preferable to incorporate a safety margin of additional capacity into the thresholds, 
because there is some potential for the information in the RSD to be slightly inaccurate or 
outdated. While Table VII only shows 2 congestion thresholds that deflne 3 congestion 
status for each link, many more thresholds and congestion status may be defined to allow 
for load balancing, overload control, and priorities for different quality-of-service traffic. 

Table VIII gives the status of the .beta.-links in the network. The information in Table 
VIII is similar to that in Table VII, but applies to .beta.-links instead of .alpha.-links. 

Table IX gives the Route Status Table. The .alpha.-links and .beta.-links associated 
with each route are identified, and the congestion status for each route is maintained. The 
congestion status can be periodically updated from the individual link congestion status 
information in Tables VII and VIII. There are many possible methods for defining Route Status 
based on Link Status. Route Status could be defined as equal to the status on the most congested 
link in the route, or as an average of the congestion status values for each link in the route. Many 
other definitions are possible, and the present invention is not intended to be limited to any 
particular set of definitions. The Route Status values in Table IX are based on using the status of 
most congested link on the route fi:*om Tables VII and VIII. . see col. 9, line 50 (Emphasis 
added). 

"For example, a particular RRSDS 740 may receive information firom several edge nodes 
720 regarding the amount of bandwidth that each of the edge nodes uses on a particular .beta.- 
link 715. RRSDS 740 may aggregate this information into a single piece of information that 
represents the total bandwidth used on the particular .beta.-link by those edge nodes 720 that are 
connected to the particular RRSDS 740. CRSDS 730 receives information fi-om each RRSDS 
740, and uses this information to compute the total bandwidth usage on each .alpha.-link and 
each .beta.-link..." see col. 13, line 36-46. 



In addition, Buyukkoc also discloses 

"A new call arrives at originating switch 270, which determines that the call is destined 
for switch 220. The (origination, destination) information is passed to the RSD, which contains 
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the information shown in Tables VII-IX. If there are different possible bandwidth 
requirements for different types of calls, the bandwidth requirement is preferably also 
passed to the RSD. The RSD uses the information in Table IX to determine that the best 
route from switch 220 to switch 270 is B2, with a congestion status of "green." The RSD 
then increments the current usage and congestion status entries for .alpha.-links 224 and 
214 in Table VII and .beta.-links 118 and 116 in Table VIII. Several techniques could be 
used to update the Status Field in Table IX. For example, it could be updated periodically, or 
upon a change in a congestion status. When the call ends, or does not make a successful 
connection, switch 220 and/or switch 270 sends another message to the RSD, and the RSD 
decrements the current usage on the applicable .alpha.-links and .beta.-links..." see col. 17, line. 
30-49. 

"Class-of-service on an end-to-end basis may be implemented using the RSD. Using 
Method 8, for example, the originating edge node passes a class-of-service indicator to the RSD 
in addition to the origination and destination information for the call. The RSD uses the Route 
Status in Table IX to give priority to the more important calls. For example, if the Route 
Status is Green, any call can use the route. If the status is Yellow, only high priority calls can 
use the route, and if the status is Red, only the most critical calls can use the route. This example 
may be generalized to additional congestion status levels. Alternatively, the RSD can route only 
a fraction of calls of lower priority on more congested routes. For example, if the Route Status is 
yellow, then a rule might be that 25% of low priority calls and all of the high priority calls can 
use the route..." see col. 18, line 25-40. 

Thus, it clear that the applicant exemplary policy/rule/plan featxires of a policy profile 
such as "burst-size limit, class-of-service provisioning, maximum concurrent call 
connections in progress, bandwidth control" clearly disclosed by Buyukkoc's SCP 
policy/rule/administration/guideline/plan/procedure/schenie having plurality of features such as 
bandwidth control/management, class-of-service, and/or loading/congestion of network (i.e. 
concurrent calls connection in progress) as defined in detailed by tables VII-IX. 

Moreover, it also clear that Buyukkoc discloses determining if a particular policy feature 
is to be invoked (i.e. bandwidth control/management, class-of-service, and/or loading/congestion 
of network (i.e. concurrent calls connection in progress) in a policy server/RSD, based at least in 
part on said signaling/request message, and if so, determining in accordance with a 
rule/policy/guide line of bandwidth control/management, class-of-service and/or 
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loading/congestion of network (i.e. concurrent calls connection in progress) for request/signaling 
message and as set forth above rejection. 

Regarding claim 10 and 13, the applicant argued that, "...Buyukkoc in no way 
discloses or suggest. . .where the particular policy feature comprises a maximum burst size limit 
feature... a maximum concurrent call limit feature..." in page 15, paragraph 1; page 15, 
paragraph 1; page 16, paragraph 1; page 17, paragraph 1-4; page 

In response to applicants argument, the examiner respectfully disagrees with the 
argument above. Buyukkoc discloses a maximum burst size limit feature (see col. 14, line 15-65; 
acceptable/maximum load/size before the call are blocked), and a maximum concurrent call 
limit feature (see coL 14, line 15-65; acceptable/maximum call load/limit). 

In general, it is also well known in the art the SCP or policy server stores policy/rule 
which contains specific policies/rules regarding the request/signaling message and determining 
according to a specific policy/rule based on associated or corresponding specific policy/rule as 
disclosed by the following prior arts. 

- Lumelsky (US006516350B1)- entire document, particularly in col. 13, line 1-19. 

- Ginzboorg (US006 14141 OA)- entire document, particularly in col. 14, line 1 1-26 

- Muir (US006661882B1)- entire document, particularly in col. 11, line 9-65 

- Bushnell (US006754322B1)- entire document, particularly in col 8, line 45-56 
In view of the above, the examiner respectfully disagrees with applicant's argument 

and believes that Buyukkoc as set forth in the rejections are proper. 
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Conclusion 

12. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 . 1 36(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed, until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

13. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Ian N. Moore whose telephone number is 571-272-3085. The 
examiner can normally be reached on 9:00 AM- 6:00 PM. 

If attempts to reach the examiner by telephone are unsuccessfiil, the examiner's 
supervisor, Doris H. To can be reached on 571-272-7629. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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